Exclude observations at lat/long 0,0 from all loads and exports (#149) - #152
Merged
Conversation
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add defense-in-depth 0,0 filtering in observationsToGeoJson and observationsToCsv so the export serializers drop null-island observations even if called with an unfiltered source list. Also guard the by-id getObservation read for consistency with the read-layer filter from #149.
Extract the duplicated !(lat === 0 && lon === 0) predicate into a single isZeroZeroCoord helper in src/lib/coords.ts, replacing 4 inline copies across local-repositories.ts (repoGetObservations filter + getObservation guard) and observation-export.ts (observationsToGeoJson + observationsToCsv filters). Add regression tests asserting that real observations on the equator (lat: 0, lon: -60) or prime meridian (lat: 45, lon: 0) are KEPT — only an exact 0,0 is excluded. This guards against over-filtering that would drop legitimate single-zero-coordinate observations.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
Contributor
|
Preview deployment ready: https://agent-comapeo-cloud-app-issu-p46s.comapeo-cloud-app.pages.dev Commit: |
The plural repoGetObservations filter already excludes 0,0 from all list/map/export reads, so the singular by-id guard was dead code with zero production callers. It also introduced an 'exists but hidden' contract (record in Dexie reported as not-found) with no test coverage, conflicting with the repo's TDD cycle. Reverting keeps the single source-of-truth filter and closes both pre-merge review nits. Flagged by Kimi K3 via the production 'PR Review for Merge Readiness' Langfuse prompt against PR #152.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Resolves #149 — exclude observations located at the exact coordinate
lat === 0 && lon === 0from all data loads and exports. A0,0coordinate is the default/null island for GPS and represents missing location data, not a real observation; leaving it in produces spurious map points and export rows.Approach
src/lib/coords.ts— adds a sharedisZeroZeroCoord(lat, lon)predicate (extracts a 4× duplicated inline check).src/lib/local-repositories.ts—repoGetObservationsfilters out0,0at the single read chokepoint that feeds both the list (data-layer.getObservations) and the map (getProjectPoints).getObservation(by-id) also returnsundefinedfor a0,0record, consistent with it never being a valid observation.src/lib/observation-export.ts—observationsToGeoJsonandobservationsToCsvfilter0,0at the serialization boundary as defense-in-depth (the read filter already excludes them upstream).Behavior notes
0,0point is excluded. A real observation on the equator (lat: 0, lon: -60) or the prime meridian (lat: 45, lon: 0) is kept — verified by new regression tests.isValidCoordvalidation downstream, so no crash.0,0observation now resolve to the observation detail screen's not-found state, since that record is no longer returned. This is accepted behavior for filtered-out records.Tests
lat:0, lon:-60observation is returned; only an exact0,0is excluded.0,0fixtures were repointed to real coordinates to prove the filter bites.Verification
npm run validate(Husky pre-push hook): lint + coverage (2276 passed / 1 skipped) + production build + i18n check — green (PASSED).origin/main(no file conflicts).Note: the repository's full-suite run is intermittently flaky on two unrelated test files —
MapScreen.test.tsx(Save Map toggle) andAddArchiveServerDialog.test.tsx(invite redemption) — which fail only under the 180-file suite and pass 60/60 in isolation. They do not import the changed code. This PR does not modify them; the failing runs were flaky full-suite passes, not regressions.